Docker images for additional travis runs #2368
Conversation
wiredfool
force-pushed
the
travis-docker
branch
from
eed7997 to
e1b943b
Compare
wiredfool
force-pushed
the
travis-docker
branch
from
e1b943b to
426f8d6
Compare
|
So, this is working now. Though, I'd feel better if the tk tests were failing. Though, it looks like this would have caught the 3.4.0 issue. |
hugovk
left a comment
hugovk
left a comment
There was a problem hiding this comment.
👍
- I've added a repo of docker files, so they can be pulled from the dockerhub. I'm not convinced that it's tons faster to do that rather than just install from bare images.
Would it be worth testing and comparing both approaches?
- I've converted a few random test docstrings so that the -v listing shows all the test names that have been run.
Perhaps skip this commit now PR #2369 is merged? Docstrings being good practice in general.
- I've re-orged the .travis.yml file, refactoring some of it into scripts so that it's easier to gate on docker/non-docker. This unfortunately removes the travis_retry verb, since it's implemented in travis, not shell.
Another downside is you just get one timing from Travis for install.sh etc, instead of timings for each separate command, making harder to optimise slow commands (for example, some pip installs have been slow for certain Pythons, and it's been possible to identify and improve some make -jX commands).
For example, compare https://travis-ci.org/python-pillow/Pillow/jobs/193782095#L249 and https://travis-ci.org/python-pillow/Pillow/jobs/193957929#L560.
Having said that, the .travis.yml file was already quite big. But if it's possible to keep some stuff in .travis.yml, that could be useful for timings in the future, especially across different platforms and Pythons.
| pyflakes *.py | tee >(wc -l) | ||
| pyflakes PIL/*.py | tee >(wc -l) | ||
| pyflakes Tests/*.py | tee >(wc -l) | ||
| fi |
There was a problem hiding this comment.
These can give different results for Python 2 and Python 3, and usually take less than 10 seconds. Perhaps keep it for all? Or was it particularly slow for some of the new Dockers?
There was a problem hiding this comment.
So, I could have sworn that this was in the .travis.yml file that I was pulling from, but I can't find it now, and I've rebased enough that it's lost.
There was a problem hiding this comment.
Ok, I've just taken these off the dockers. (Note that TRAVIS_PYTHON_VERSION in the docker runs is the python version in travis, not in the docker image, so it's pretty much irrelevant at this point, and could fundamentally mismatch)
That was written before I pulled the compiled dependencies into the images. That saves 15-30 seconds. It's disappointing that on a local cached run, it's 10-15 seconds, but the runs on travis are measured in minutes. But there's downloading and post script setup stuff. Apart from that I think having the testing images on dockerhub is useful for others to pull and test against when debugging failures. e.g:
Yeah, I noticed that. The |
|
Also worth noting -- I'm planning on adding a virtualenv parameter to the docker args so that we can test against alternate pythons on the same image. (e.g. system py2 and py3) And unrelated, we could probably add a make environment argument in travis to do the -j thing, so it wouldn't need to be hard coded for anyone who's got a single proc vm. |
2 participants
Fixes #2152.
This is a big, in progress refactor and addition.
I've converted a few random test docstrings so that the -v listing shows all the test names that have been run.I'm going to at least rebase the many commits this prior to merge.And the big one -- Tests are failing:
There are actual failing tests on the trusty one.Precise is hanging, I think on Jpeg2k. It doesn't do it OMM, where I'm building the docker image. (go figure).